X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C91E84.73076238@onstor-exch02.onstor.net>; Wed, 24 Sep 2008 13:30:57 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: RMC RPC API
Date: Wed, 24 Sep 2008 13:30:56 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0BBADD3E@onstor-exch02.onstor.net>
In-Reply-To: <20080924120455.33b156be@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RMC RPC API
Thread-Index: AckeeG62gFB5NYuJTXuG7bO8oRs2DAABfg8g
References: <BB375AF679D4A34E9CA8DFA650E2B04E0BAC8B1C@onstor-exch02.onstor.net><20080923172220.1e32cd5f@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E0BAC9158@onstor-exch02.onstor.net> <20080924120455.33b156be@ripper.onstor.net>
From: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>
Cc: "dl-Design Review" <dl-designreview@onstor.com>


>I'm not talking about making the task of implementing the select loop
>easier, I'm talking about implementing the trivial case in an API
>function called rmc_read_ or rmc_wait_message or something, which would
>get a lot of use if it existed.  Which is kind of the point of APIs.
>Or one of the points, anyway.
[MK]=20
If you are suggesting creating function which combines rmc_get_fds(),
select, and rmc_dispatch() in a single function, I would put it into
"making writing select loop easier" category and defer this to another
day. We have a bunch of applications most of which have to implement
some sort of the request management and some sort of select loop,
everybody does it differently and poorly. We need to extract some common
request management API out of this m[a|e]ss of code, I think the
functionality you want belongs there and not in this API.=20

>>Possibly it doesn't belong in this doc.  Perhaps this doc could have a
>ref to the other one, which I didn't know existed.
[MK]=20

The RMC docs are in nfx-tree/code/ssc-rmc/design. I'll add a reference
if I'll make another revision.

>
>> >page 18

>It shouldn't require any additional parameters, which I was trying to
>hint at when I said a unique arbitrary string should suffice.  If
>rmc_init_ex hasn't been called, the _init method can create an
>arbitrary, notice I didn't say random, unique string and use that.  If
>the app itself doesn't care, then neither does anything else.
[MK]=20
Even if I can get rid of the extra arguments I still would like to have
an init function which must be called before anything else. Having
everybody call an init function makes it easier to extend the API.
Suppose I would get rid of an init function and make rmc_client_init()
or rmc_server_init() call it, and suppose I can make it so that no
additional arguments required. Then if for some reason I need to add an
argument, I would have to hunt down each invocation of rmc_client_init()
and rmc_server_init() and modify them. If I have an init function I need
to modify only the init function invocations. I don't think that having
an init functions puts an undue burden on the users, as long as the
failure to call the init function can easily be diagnosed.=20


